of said discrete event sequentially and stores the processed discrete event . 
Please cancel claim 28, without prejudice. 

REQUEST FOR RECONSIDERATION 
No new matter is added by these amendments, and the amendments to claims 1,14, 
and 27 are fully supported by the specification. Applicants respectfully request that the Examiner 
enters these amendments and that the Examiner reconsiders the above-captioned patent application 
in view of the foregoing amendments and the following remarks. 

Upon entry of these amendments, claims 1-27 will be pending in the above-captioned 
patent application. As per the Examiner's request and in order to expedite the processing of the 
application, Applicants are enclosing the text of all claims remaining in the application after entry of 
the foregoing amendments. Office Action, Page 13, Lines 1-9. 

REMARKS 

1. Rejections 

Applicants acknowledge with appreciation that the Examiner has allowed claims 8, 
9, 22, and 23. However, claims 1, 4-7,10-15, 18-21, and 24-26 stand rejected under 35 U.S.C. § 103 
as allegedly rendered obvious by U.S. Patent No. 5,179,702 to Spix et al ("Spix") in view of U.S. 
Patent No. 5,305,454 to Record et a[. ("Record")- Further, claims 2, 3, 16, 17, 27, and 28 stand 
rejected under 35 U.S.C. § 103 as allegedly rendered obvious by Spix in view of Record, and further 
in view of U.S. Patent No. 5,303,297 to Hillis. These rejections were made final by this Office 
Action. Applicants respectfully disagree. 

2. Claims 1. 14. and 27 

a. Definition of Segments. Events, and Threads 

In response to the previous Office Action, mailed January 17, 1996, Applicants argued 
"that a thread cannot be both a segment and an independent sub-event, as claimed. As recited in 
claims 1, a segment comprises a plurality of discrete events, each discrete event comprising a plurality 
of independent sub-events." Office Action, Page 2, Lines 7-9. The Office Action noted that, as 
originally filed, claim 1 recited that "each segment compris[es] a sequence of at least one discrete 
event to be processed." (Emphasis added.) Consequently, the Office Action asserted that " a single 
discrete event meets the limitations associated with a 'segment' " Office Action, Page 2, Lines 10-12 
(emphasis in original). Therefore, Applicants have amended claims 1, 14, and 27 to describe "a 
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segment comprising a sequence of a plurality of discrete events/' to conform the language of these 
claims with the arguments in Applicants' previous response. (Emphasis added.) 

The Office Action again contends that "Spix teaches that each independent 'sub-event' 
(i.e., 'thread') is processed sequentially as determined by priority . . ." Office Action, Page 6, Lines 
22-24. The Office Action acknowledges, however, that "a clear distinction exists between an event 
and a thread." Office Action, Page 2, Lines 13-15. Because the "segment" is described as 
executable, the Office Action interprets the scope of the term "segment" to include a discrete event 
and the code, process(es), or thread(s) that process or handle the discrete event. Office Action, Page 
3, Lines 3-6. Further, the Office Action notes that ft is the claimed subject matter, and not the 
specification, that defines the invention, and consequently contends that "segment" is entitled to a 
broad interpretation. Office Action, Page 5, Lines 7-11. 

The issues raised by the Office Action's assertions are (1) whether Spix's "process 
queues" describe Applicants' "segments" and (2) whether Spix's "threads" describe Applicants' "sub- 
events." Office Action, Page 6, Lines 20-24. In view of the foregoing amendments, Applicants 
maintain that the Office Action has provided no evidence that Spix's "process queues" comprise a 
sequence of "a plurality of discrete events to be processed. Appl'n, Claim 1 (as amended). Further, 
the Office Action's earlier acknowledgment that "a clear distinction exists between an event and a 
thread" (Office Action, Page 2, Lines 13-15) contradicts its later contention that a sub-event is a 
thread. Office Action, Page 6, Lines 22-24 ("each independent 'sub-event' (i.e., 'thread')"). 
Moreover, according to Spix, "[a] thread is a part of a program that is logically independent from 
another part of the program and can therefore be executed in parallel with other threads of the 
program " Spix, Column 2, Lines 9-12. Thus, a thread is an independent sequence of logic that may 
be executed separably, and contrary to the Office Action's assertion, a sub-event is not a thread. 

In the specification, Applicants explain that: 

Batch processing . . . comprises processing a plurality of discrete events. As 
used herein, the term "discrete event" is not limited to a time specific occurrence, but 
rather a collection of data which is to be processed to generate an outcome. 
Preferably, each discrete event comprises a plurality of sub-events. Each sub-event 
is also data which is to be processed. In a preferred embodiment of the present 
invention, when applied to the cellular phone customer account processing, each 
customer account to be processed is treated as a discrete event. Further, since a 
number of details regarding the customer account must be processed, for example, 
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recurring charges, non-recurring charges, taxes, customer calls, accounts receivable, 
etc., each of the details is treated as a sub-event which may be processed separately . 
Appl'n, Page 22, Lines 13-22 (emphasis added). Clearly, a sub-event, e.g. , data, may be processed . 

but is not executed . Similarly, a thread may be executed in order to process a sub-event. Therefore, 

Applicants maintain that Spix's process queue is not a segment and that a thread is not an 

independent sub-event. 

b. Processing Order 

In Applicants' response to the previous Office Action, Applicants argued that "Spix 

discloses and teaches using priority. Prioritization schemes are not sequential." See Office Action, 

Page 4, Line 1. In response, the Office Action asserts "that processes or threads executed in a 

particular priority are still executed sequentially in the order determined by their priority ." Office 

Action, Page 4, Lines 1-3 (emphasis added). Nevertheless, as discussed below, priority processing, 

sequential processing, concurrent processing, and serial processing are different and distinct 

processing methods. Further, although the Office Action asserts that Spix describes "concurrent" 

program execution, the cited text does not support this assertion. See Office Action, Page 6, Lines 

20-22. 

Spix is directed to the processing of threads according to a predetermined priority 
(Spix, Column 29, Lines 53-68, and Column 30, Lines 1-19; see also Office Action, Page 6, Lines 
22-24), and "priority processing" is "[a] method of computer time-sharing in which the order in which 
programs are processed is determined by a system of priorities, involving such factors as length, 
nature and source of the programs." McGraw-Hill Dictionary of Scientific and Technical Terms, 
1495 (4th ed. 1989) (copy enclosed). Applicants' claimed invention, however, describes 
"concurrent" execution of segments and "sequential" processing of discrete events and sub-events. 
See Appl'n, Claims 1, 14, and 27 (as amended). Unlike Spix's "priority processing" of threads, 
Applicants' "concurrent processing" is defined as "[t]he conceptually simultaneous execution of more 
than one sequential program on a computer or a network of computers." Id. at 407 (copy enclosed). 
"Sequential processing," however, is defined as "[processing items in a collection of data according 
to some specified sequence of keys in contrast to serial processing " Id. at 1704 (copy enclosed; 
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emphasis added). 1 

(i) Concurrent Execution 

The Office Action asserts that "Spix teaches that a plurality of segments (i.e., 'process 
queues') are initiated to execute concurrently on at least one processor [col. 9, lines 10-15] " Office 
Action, Page 6, Lines 20-22 (emphasis added). Nevertheless, the cited text of Spix merely states that 
a User-Side Scheduler "can both place work in the request queues in the OSSR [sic] and look for 
work to be done in the same request queues." Spix, Column 9, Lines 1 1-14. Spix clearly states that 
"[t]he order of the work to be done in the request queue is determined by prioritization of the 
processes ." Id. at Lines 14-15 (emphasis added). Therefore, Spix describes priority processing and 
does not teach concurrent execution of segments. 

(ii) Sequential Processing 

The Office Action contends that, despite the deficiencies of Spix, Record "teaches 
events and related 'sub-events' that are processed or handled in a sequential manner: ' A program can 
specify interest in a combination of events of the same or different types and if the propagation mode 
is selected, each event handler in a sequence which receives notification of an event can decide to 
propagate any number or none of the event signals of interest .'" Office Action, Page 3, Lines 19-23 
(quoting Record, Column 3, Lines 12-18 (emphasis in original)). Applicants' claimed invention 
describes the processing of a plurality of discrete events in a batch processing environment. Record, 
however, describes an operating system which manages resources for handling events. Specifically, 
Record describes a first event handler determining whether a second event handler should be notified 
of an event and the second event handler determining whether a third event handler should be notified 
of the event. See Record, Column 16, Lines 3-8; Fig. 8. Record explains that "[i]n this manner, the 
event notification can be propagated from event handler to event handler in sequence, but any event 
handler in the sequence which receives notification can block subsequent propagation of the event 
notification." Record, Abstract. 

In Record, "[a]fter receiving notification that the event monitor is satisfied, the event 
handler can retrieve and process event data. The manner of interpreting the event data is based on 



1 "Serial processing" is defined as "[processing items in a collection of data in the order that 
they appear in the storage device, in contrast to sequential processing." Id. at 1705 (copy enclosed). 
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a private protocol between the event signaler and event handler , and is established separately for each 
named event. The event management services within operating system 1 1 provides a channel for 
delivering the event notification and event data to the event handler." Record, Column 5, Lines 5-13 
(emphasis added). The event monitor determines what types of events are received by the first event 
handler, and the first event handler determines whether later event handlers even receive the event 
data. Thus, Record employs the sequential screening of events to allocate event handlers to the 
processing of event data. Therefore, Applicants maintain that Record does not describe the sequential 
processing of discrete events and that the Office Action has not shown that the combination of Spix 
in view of Record discloses or suggests Applicants' claimed invention having concurrent segment 
execution and sequential processing of discrete events. See Appl'n, Claims 1, 14, and 27 (as 
amended). 

In Applicants' previous response, Applicants also asserted that the Office Action has 
failed to show that there is a motivation to combine Spix with Record. Citing In re McLaughlin , the 
Office Action correctly points out that the motivation need not be expressly articulated in the 
references. 170 USPQ 209 (CCPA 1971). However, the Office Action then incorrectly relies on the 
"event handling capabilities " of the operating system environments described in Spix and the known 
uses of the IBM equipment described in Record to allegedly provide a motivation to combine these 
references. Office Action, Page 4, Lines 14-22. Nevertheless, "[t]hat which is within the capabilities 
of one skilled in the art is not synonymous with obviousness." In re Levengood . 28 USPQ2d 1300, 
1302 (Bd of Pat. App. & Int'f 1993); see also MPEP 2143.01 (citing Levengood with approval). 
That these references could be combined, does not demonstrate that a person of ordinary skill in the 
art would be motivated to combine them to arrive at the claimed invention. Id. at 1301. "The test 
under § 103 is not what 'one might contemplate.' The proper test is whether the references taken 
as a whole, would suggest the invention to one of ordinary skill in the art." Medtronic Inc. v. Cardiac 
Pacemakers. Inc. . 220 USPQ 97, 1 10 (Fed. Cir. 1983). Thus, the "legendary" capabilities of IBM 
equipment do not provide a motivation to combine these references to produce Applicants' claimed 
invention. 

Finally, while the Office Action notes that any judgment on obviousness is in some 
sense necessarily a reconstruction based upon hindsight reasoning (Office Action, Page 5, Lines 1-2), 
the appropriateness of such a "reconstruction" rests on the existence some motivation to combine the 
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cited references as suggested by the Office Action and the teaching of the elements of the claimed 
invention by the cited references. As discussed above, Applicants believe that the Office Action has 
failed to demonstrate such motivation and that Spix and Record fail to disclose or suggest all of the 
claimed elements. MPEP 2143. Further, the Office Action does not contend that Hillis provides the 
elements of Applicants' claimed invention that are missing from Spix in view of Record. 

In view of the foregoing amendments and remarks, Applicant respectfully requests that 
the Examiner withdraws the rejections of claims 1,14, and 27. Moreover, in accordance with MPEP 
2143.03, "[i]f an independent claim is nonobvious under 35 U.S.C. § 103, then any claim depending 
therefrom is nonobvious." Therefore, Applicant respectfully requests that the Examiner withdraws 
the rejections of claims 2-7, 10-13, 15-21, and 24-26, as allegedly rendered obvious by Spix, alone 
or in combination with other references. 

CONCLUSION 

Applicants submit that this application, as amended, is in condition for allowance, and 
such disposition is earnestly solicited. If the Examiner believes that an interview, either in person or 
by telephone, with Applicants' representatives would further the prosecution of this application, we 
would welcome the opportunity to do so. 

Respectfully submitted, 
BAKER &BOTTS, L L P. 

Dated: December 4, 1996 
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